Since the introduction of the first version of Session Initiation Protocol (SIP) published in 1999, there has been a menagerie of network architectures that have adopted SIP as the protocol to support call control. These networks are of many types, from basic networks using SIP end-to-end to connect SIP user devices, to networks using SIP to bridge between Public Switched Telephone Network (PSTN) gateways, to the latest subsystems in support of next generation networks that are intended to replace existing PSTN networks. Early efforts to describe interworking to the PSTN and support of services within the IP network were document by the IETF PINT (PSTN/Internet Interworking) and SPIRITS (Services in PSTN requesting Internet Services) working groups. These efforts subsequently lead to the formal protocol extensions upon which much of today's SIP based networks and services rely. To allow SIP to continue to evolve new capabilities over time, the IETF has built into SIP version 2.0 several effective mechanisms that allow endpoints to negotiate the use of different capabilities and extensions. The SIP Supported header allows an endpoint to signal which SIP options are supported. The SIP Required header allows an endpoint to signal which SIP options are required to be used during a session. The SIP Accept header indicates which Multipurpose Internet Mail Extensions (MIME) attachments are recognized. There is also a caller preferences mechanism available to indicate a caller's preferences regarding the use of certain SIP features throughout the network.
Even with these useful mechanisms for SIP endpoints to negotiate between themselves to a common set of capabilities, multiple SIP networks have evolved over time into separate islands that cannot always be directly interconnected and may have significant compatibility issues when they are interconnected. As depicted in FIG. 1, these disparate networks 102, 104, 106, 108 in a telecommunication network 100 may require interworking gateways 110, 112, 114, 116, 118, 120 to adapt between nuances of these networks 102, 104, 106, 108. For example, a SIP network based on ITU-T Q.1912.5 profile C (referred to as SIP-I—SIP with encapsulated ISUP (Integrated Services Digital Network User Part)), which is typically configured to bridge PSTN gateways, is designed to support interconnection only between trusted endpoints in a closed network, due to the mandatory use of encapsulated ISUP messages, the presence of information within the encapsulated ISUP messages that is private to the network, conventions regarding early media, and other differences with conventional SIP usage. Any connection to a SIP endpoint outside of a trusted SIP-I domain must be through an appropriate gateway. Other SIP networks have been deployed using various proprietary extensions to support needed customer features, and these networks are not always compatible with one another. Even the IETF version of SIP carrying encapsulated ISUP (SIP for Telephones—SIP-T), which is similar to SIP-I in the use of encapsulated ISUP, is incompatible in design with SIP-I due primarily to differences in their security models. Internet Protocol (IP) Multi-Media Subsystem (IMS) SIP (Q.1912.5 profile A) is incompatible with some of the SIP security extensions defined by the IETF.
Packet technology is being introduced into the Public Switched Telephony Network (PSTN) and Public Land Mobile Network (PLMN). This Session Initiation Protocol (SIP) is being used to provide the call control signaling in these packet networks. but various networks are using different versions (i.e., Profiles) of SIP to support services within these networks. This makes it increasing difficult to allow interconnection between networks while continuing to support the desired and expected level of service. Of particular interest is the continued support of ISUP based services when using SIP. It is necessary to detail the means by which nodes of differing level of support of ISUP information being carried within the SIP signaling are able to interoperate.
The following is an overview of some significant types of SIP networks. Each network has specific requirements on the use of SIP, defining a SIP specific to that network. Each such usage of SIP will be referred to as a SIP profile. In some networks, SIP is used end-to-end to interface to both the user (user-network interface—UNI) as well as between network components (network-network interface—NNI). Even though there are many different organizations and standards bodies defining these networks, it is possible to group SIP networks according to some common characteristics.
FIG. 3 depicts end-to-end native SIP networks. For example, in a telecommunication network 300 a SIP network 302 is operatively coupled to a PSTN 304 via a gateway 306. The SIP network 302 may be operatively coupled to SIP terminals 308, 310, 312, as well as to other SIP networks 314.
Native SIP networks use only the information inherent in “native” SIP headers between endpoints to control session state. SIP allows for the encapsulation of ISUP signaling information as attachments to SIP messages to signal additional PSTN service information not available in SIP, but these “native” SIP networks do not use this feature of SIP. The public Internet, IMS networks and other networks designed to directly serve native SIP terminals typically assume such a use of SIP. These networks use SIP as defined in RFC 3261 with additional “native” SIP extensions defined in other IETF RFCs to support various services, e.g., the Subscribe/Notify capability defined by RFC 3265. The extensions introduce new headers that allow service information to be carried between SIP endpoints. For these networks, standard PSTN supplementary service capabilities are provided to SIP terminals only to the extent that the native SIP is able to carry the associated service information. If the service information cannot be mapped into SIP headers, some or all of the service capabilities are lost. Therefore, when these networks interconnect with either the PSTN or other SIP networks that are able to more fully support the services, interworking will result in a reduction of capabilities. It has historically not been the intention of the IETF to extend SIP to parallel the capabilities of ISUP. Instead those PSTN services emulated within SIP have been modified to more closely match the capabilities of SIP.
FIG. 4 depicts networks that bridge ISUP networks. For example, in a telecommunication network 400 a SIP network 402 may be operatively coupled to a PSTN 404 via a gateway 406. The SIP network 402 may also be operatively coupled to another PSTN 410 via a gateway 408.
Such networks bridge ISUP networks but do not directly support SIP-enabled terminals. These networks use many of the capabilities of native SIP, but supplement those capabilities through the use of encapsulated ISUP to transparently carry additional service information between ISUP networks. Such networks are defined by the SIP-T and SIP-I profiles of SIP. Other network types such as IMS and the TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks) simulation network may also bridge ISUP networks during redirection/forwarding scenarios, but that is not their primary role, which is to support SIP-enabled terminals. The use of encapsulated ISUP enables the support of PSTN supplementary services by allowing SIP-to-PSTN/ISUP gateways to make use of the available ISUP information. The SIP header information takes precedence over any encapsulated ISUP. The encapsulated ISUP then fills the gaps where there is no SIP header that is able to carry the service information.
One of the goals of the Next Generation Networks (NGN) emulation model is to provide a replacement for the existing PSTN infrastructure while supporting service transparency. Even though the network infrastructure is being replaced, the user's service experience should be unchanged. The NGN PSTN/ISDN Emulation Subsystem (PES) is a packet switching SIP network that can be realized through two different architectures: softswitch-based and IMS-based.
FIG. 5 depicts an IMS based PSTN/ISDN Emulation Subsystem (PES). For example, in a telecommunication network 500 a PSTN/ISDN Emulation Subsystem (PES) 502 may be operatively coupled to a PSTN 530, to terminals 518, 520 via gateway (GW) 514, to terminals 522, 524 via media gateway (MG) 516, and to application server (AS) 512. The PES 502 may have a S-CSCF 504, I-CSCF 506, P-CSCF 508, AGCF 510, BGCF 526, and MGCF 528.
The IMS-based PES inherits the same network architecture as defined by the 3GPP IMS with a number of modifications. The interface point into the PES has been modified to accommodate the presence of circuit end points such as the basic analogue residential telephones, ISDN phones or Private Branch Exchanges (PBXs). The NNI between the PES components and the Application Servers that provide the subscriber and network services uses encapsulated ISUP to signal supplementary services information. The use of encapsulated ISUP allows ISUP aware entities, e.g., Application Servers supporting PSTN/ISDN emulation logic, to provide feature transparency to the circuit end points when signaling among Application Servers and PSTN gateways. The UNI does not require ISUP encapsulation but does need other extensions not discussed herein to control interactions with end-user devices.
FIG. 6 depicts softswitch-based architecture. For example, in a telecommunication network 600 a PSTN/ISDN Emulation Subsystem (PES) 602 may be operatively coupled to a PSTN 618, to other NGNs 620, to application server (AS) 608, to terminals 612, 614 via AGF 610, and to RG 616. The PES 502 may have a service logic control 604, a SGCF & TGCF 606, and AGCF 607.
In the softswitch-based architecture, a Media Gateway Controller (MGC) implementing the PES functional entities along with Access Gateways (AGWs) and Residential Gateways (RGs) are used to replace the existing class 5 local exchanges. The AGWs and RGs support the existing circuit end points and are controlled using H.248/MEGACO. The softswitch controller supporting the PES then provides existing services as well as supporting the introduction of new services through the use of additional Application Servers. To accomplish feature transparency the softswitch controller, and possibly the Application Servers, must be ISUP aware. A Signaling Gateway Control Function (SGCF) provides the interface to the existing PSTN, while signaling to other NGNs uses SIP-I. By doing so, it enables the softswitch controller to continue to provide all the same services in the same manner that the user has come to expect; the user behavior need not change just because the support network has evolved.
FIG. 7 depicts a PSTN/ISDN Simulation Subsystem (PSS). For example, in a telecommunication network 700 a PSTN/ISDN Emulation Subsystem (PES) 702 may be operatively coupled to a PSTN 722, to other SIP networks 720, to terminals 710, 712, and to application server (AS) 714. The PES 702 may have a S-CSCF 704, I-CSCF 706, P-CSCF 708, BGCF 716, and MGCF 718.
The NGN PSS differs from the emulation model described above in that it is strictly an IMS-based architecture used to serve native SIP terminals that are enhanced to provide additional simulation services. The simulation services are simulated versions of the most valuable PSTN supplementary services. However, since it is inappropriate to signal encapsulated ISUP on the UNI to the end-user terminals, new SIP extensions are being introduced to address the gaps. The NNI is also likely to use some of these SIP extensions, but the exact nature of the NNI is still under discussion within the community. There is a desire to maintain full services transparency when interworking with other network types while there is also a desire to avoid promulgating the need to process ISUP messages throughout the network. The resulting NNI profile will have difficulty fully achieving these apparently conflicting goals.
Although instances of the architectures described above use many different SIP profiles, the two main classes of SIP profiles are those that don't use ISUP encapsulation (e.g., IMS SIP) and those that do (e.g., SIP-I and SIP-T). The following are the differences between two SIP profiles that represent each class, IMS SIP and SIP-I. These versions of SIP are referred to as profiles A and C of ITU-T Recommendation Q.1912.5, respectively.
Profile C uses encapsulated ISUP in SIP messages between signaling entities in a trusted domain. The encapsulated ISUP provides for signaling of additional information, including supplementary service information that is not available within SIP. The encapsulated ISUP is marked for mandatory disposition within the SIP messages. A sender of encapsulated ISUP with mandatory disposition assumes that the recipient is able to process and properly respond to any ISUP content not redundant with SIP header information. The receiver of a SIP message with an attachment marked with mandatory disposition is obliged to reject the SIP request if it does not recognized the attachment type. Profile A does not use encapsulated ISUP and is limited to supporting only a subset of the supplementary services as described in Annex B of ITU-T Recommendation Q.1912.5, and of the ones “supported” not all functionality is provided.
Profile C encapsulates two categories of ISUP messages: those that provide information to augment existing SIP session management procedures; and those associated with ISUP procedures that have no SIP counterparts. For example, the ISUP call setup message, the Initial Address Message (IAM), serves to augment information in the SIP INVITE request, while the ISUP message used to obtain the calling party's identity, the Identification Request (IDR) message, is carried in a SIP INFO request since it is not associated with a SIP session management procedure.
Default values exist in profile A for all mandatory ISUP information to be applied when interworking with ISUP since there is no encapsulated ISUP associated with profile A SIP session management procedure messages. Profile A does not use the SIP INFO request for interworking purposes since it does not support ISUP procedures not associated with SIP session management.
Profile C supports signaling of the ISUP Forward and Backward Call Indicators across a SIP network. These indicators provide information related to the nature of the connection. The most significant information passed in these parameters is for echo control, allowing allocation of only the minimum required echo control units. Since a profile A network cannot signal echo control information, it will typically assume that echo suppression is handled locally before reaching the SIP network.
A profile C interworking unit always behaves like a transit exchange, performing cut-through in both directions as soon as possible and providing no call progress tones. A profile A interworking unit may take on some of the characteristics of an originating or destination exchange with respect to cut-through and call progress tones, since it may be directly connected to a SIP UE (user equipment). For example, a profile A Inter-Working Unit (IWU) with SIP on the outgoing side may provide call progress (in-band ringing) based on the receipt of a 180 (Ringing) response to a SIP INVITE request, and a profile A IWU with SIP on the incoming side may perform forward cut-through only upon sending a 200 (OK) response to a SIP INVITE request.
A profile C interworking unit is able to communicate the Suspend and Resume messages used by the Terminal Portability service simply by encapsulating them in a SIP INFO request without affecting the call state or the bearer. However, a profile A endpoint is not able to indicate the event in a non-impacting manner. Since it is desirable to inform the other party of the event, the Terminal Portability events at a profile A interworking unit are represented in a similar manner as Call Hold. The end result is a close approximation, but still not a true representation of the service.
As a result of the differences above, profile C supports signaling for all of the supplementary services while profile A only supports a subset. For those services not supported, profile A must either reject the call, or continue the call with a subset of the capabilities of the service. In the latter case, profile A may perform the service but fail to deliver status information to endpoints, and/or it may fail to perform some portion of the service.
Therefore, there is a need in the art for a system in which different networks may be directly interconnected and be compatible with one another.